Graphical user interfaces that enable a user to manipulate graphical symbols or items representing objects are generally known. For example, U.S. Pat. No. 5,542,086 shows an object-oriented operating system in which object classes are classified to a file object from different computer systems at the level of the operating system.
Further, U.S. Pat. No. 5,710,894 shows an apparatus for providing dynamic classification of objects. The dynamic classification of objects is performed within a simulator environment using a graphical user interface related to the simulator environment.
Typically, hierarchies that help to structure assignments between objects are administrated through graphical user interfaces (GUIs). Examples of such GUIs include the Microsoft Windows Explorer or the cost assignment view of ABC Technologies OROS program.
For example, in Microsoft Windows Explorer, a folder structure is built in the form of a hierarchy. Objects of three different object types (folders, files and shortcuts) may be graphically assigned to a folder. The computer user, in the following referred to as “user,” maintains the hierarchy through:                (a) a combination of menu entries in the drop down menus of the Windows Explorer,        (b) menu entries in a context menu launched with the right mouse button, and        (c) “drag & drop” functions launched with the left or right mouse buttons. Also, shortcuts via the keyboard may be used. For example, new folders or shortcuts may be created by selecting an appropriate menu entry from the “File” menu or from the context menu; for instance, folders or files may be moved or copied by using the right mouse button for “drag & drop”. Files, folders or shortcuts may be deleted by using the context menu with the right mouse button. For each object type, only specific activities are allowed. For instance, a folder cannot be graphically assigned to a file or shortcut. A shortcut cannot be graphically assigned to a file but is assigned to the tile in a logical relationship.        
The OROS program referenced-above allows the user to graphically define assignments between objects of two different hierarchies. Both hierarchies work similar to the Windows Explorer logic for adding, moving or deleting objects. Both hierarchies support three different object types: center type, account type and cost element type.
For example, a first hierarchy shows the resource view of an enterprise. A center may define a group of resources. Centers may be assigned to other centers. An account may define a specific resource, such as a machine or a building. Accounts may be assigned to centers. A cost element defines a specific type of cost, such as salary, rent etc. Cost element may be assigned to accounts.
A second hierarchy, for example, shows the activity view of an enterprise, where centers define groups of activities, accounts define activities and cost elements, again, define specific types of cost. Similar to the first hierarchy, cost elements are assigned to accounts and accounts are assigned to centers.
When the user creates an assignment between objects of the first hierarchy and the second one, only accounts of the first hierarchy may be assigned to accounts of the second hierarchy and vice versa. The graphical user interface supports this assignment, for example, by displaying the first hierarchy (sender objects) within the first frame and only the accounts of the second hierarchy (receiver objects) as a flat object list within a second frame. When the user selects an account of the first hierarchy in the first frame, an account in the second frame became a possible target for the assignment. This is indicated by little arrows icons next to each of the accounts in the second frame. To create the assignment the user selects one account in the second frame by clicking on the corresponding arrow icon and finally enters an assignment category and an assignment value to specify the assignment.
These examples work very well with applications that only use a limited number of object types (three in the examples above) with a limited number of possible relationships between these objects. Therefore, they provide an easy-to-use solution for graphical maintenance of assignments in application systems that do not show a high degree of complexity as far as the number of object types and their possible dependencies are concerned. However, more complex application systems, such as Enterprise Resource Planning (ERP) systems (e.g., mySAP ERP) usually support a much higher number of object types. Also, the number of possible relations between the various object types is very high.
When applying conventional user interface models to complex application systems, such as ERP systems, the user encounters some inconveniences when creating assignments within or across hierarchies. This becomes obvious when looking at a typical organizational structure of an enterprise in an ERP system from a cost management point of view.
For example, in the SAP ERP system, a controlling area defines an area that is relevant for an enterprise from a cost management point of view. In each controlling area, a hierarchy of cost center groups is defined. Multiple cost centers are assigned to a cost center group. For each cost center multiple cost elements are assigned either directly to the cost center or to activities of the cost center. Cost elements may be grouped into cost element groups. In a further hierarchy, internal orders may be defined. Cost centers with cost element groups or activities may be assigned to internal orders. On the other hand, internal orders may be assigned back to cost centers. The same is true for projects and project elements. Cost center activities may also be assigned to production or sales orders. For convenience of explanation, further object type relations are not listed here. Numerous further object types and their possible relations to other object types within the same or across hierarchies may be taken from “CO-I Overhead Cost Controlling”, published in September 1999 by SAP AG (Walldorf, Germany).
Users desire a clear visualization of all actual and possible dependencies between object types. For assignments across hierarchies, a flat list of receiver objects, as in the above-noted example, would contain a large amount of objects of different object types. This leaves the task to identify the right receiver object for an assignment completely with the user (e.g., by applying the right mouse button to every single object). To identify the receiver object is difficult because the information about the location of the receiver object within the hierarchy is hidden.
This problem is addressed by a method and computer system for graphical assignments in hierarchies known from European Patent Document EP 1331553 A1. This method enables the entry of object assignments within and across hierarchies for applications using a large number of object types with a large number of object type relations.
Embodiments consistent with the present invention aim to provide improved methods, computer program products and data processing systems for entering object assignments and addressing one or more of the above-identified drawbacks.